WebSocket is a protocol that provides full-duplex, persistent communication channels over a single TCP connection, enabling real-time bidirectional data flow between client and server, fundamentally different from HTTP's request-response model.
WebSocket is a communication protocol designed for real-time, bidirectional, and full-duplex communication between a client (like a web browser) and a server. Unlike HTTP, where the client must initiate every request, WebSocket allows the server to push data to the client at any time, making it ideal for applications requiring live updates such as chat applications, online gaming, financial trading dashboards, and collaborative editing tools. The protocol starts with an HTTP handshake and then upgrades the connection to the WebSocket protocol.
HTTP handshake: The client sends an HTTP request with an
Upgrade: websocketheader, indicating it wants to switch to the WebSocket protocol .Protocol upgrade: If the server supports WebSocket, it responds with a
101 Switching Protocolsstatus code, and the connection is upgraded .Persistent connection: After upgrade, the TCP connection remains open, allowing both client and server to send messages at any time .
Full-duplex communication: Data can flow in both directions simultaneously, unlike HTTP's half-duplex where one side waits for the other .
Framed messages: WebSocket uses a lightweight framing format with small overhead (2-14 bytes per message), efficient for many small messages .
Close handshake: Either party can initiate a close handshake to terminate the connection gracefully .
Communication model: HTTP is request-response (client asks, server answers). WebSocket is full-duplex (both sides can send anytime) .
Connection lifetime: HTTP connections are typically short-lived (closed after response). WebSocket connections are long-lived and persistent .
Overhead per message: HTTP has significant header overhead per request (hundreds of bytes). WebSocket has minimal framing overhead (2-14 bytes) .
Directionality: HTTP only allows server to respond to client requests. WebSocket allows server to initiate communication .
Statefulness: HTTP is stateless by design (though cookies/sessions add state). WebSocket maintains connection state throughout .
Protocol layers: HTTP is application layer; WebSocket operates over TCP but with its own framing, often layered on HTTP for handshake .
Browser support: Both are well-supported, but WebSocket requires modern browsers and server configuration .
The fundamental difference is that HTTP was designed for document retrieval—a client asks for something, and the server delivers it. WebSocket was designed for conversations—a continuous, bidirectional exchange of messages. In HTTP, if the server wants to send data to the client, the client must have previously requested it (polling) or the server must trick the client into requesting it (long-polling, server-sent events). WebSocket eliminates this asymmetry.
Message types: Can send text (UTF-8) or binary data (Blob, ArrayBuffer) .
Subprotocols: Can negotiate subprotocols like MQTT, STOMP, or custom protocols during handshake .
Extensions: Support for compression (permessage-deflate) and other extensions .
Heartbeat/ping-pong: Built-in ping/pong frames to keep connections alive and detect disconnections .
Cross-origin: Uses Origin header for security, similar to CORS .
Secure WebSocket (wss://): Encrypted version over TLS, analogous to HTTPS .
For the JavaScript engine, WebSocket is an API provided by the browser or Node.js runtime, not a feature of the language itself. When you create a WebSocket in JavaScript, the engine delegates to the underlying platform's networking stack. The event-driven nature of WebSocket callbacks (onopen, onmessage, onclose, onerror) integrates seamlessly with JavaScript's event loop, making it natural to handle real-time events without blocking.
The choice between HTTP and WebSocket depends on the application needs. HTTP remains the right choice for REST APIs, static content, and request-response patterns. WebSocket is the right choice for real-time features, live updates, and bidirectional communication. Modern applications often use both: HTTP for standard API calls and WebSocket for real-time push. Understanding this distinction helps architects design systems that use the right tool for each job.